Many modern computing environments use some form of a software package management system to manage the lifecycle of software applications installed on the system. A software package management system is a collection of tools for automating the process of installing, upgrading, configuring, and removing software application packages from a computer. In computer systems that utilize software package management systems, software (e.g. an application), is distributed in packages usually compiled into a single file. A software package generally includes software files that are required for installation of the software and a mechanism that is implemented so that a user can install the software on a computer or later uninstall the software. Software packages also include a list of other software packages, known as dependencies, which are required for the software to run properly. Software package management systems organize all of the software packages installed on a system and maintain the usability of the software packages.
FIG. 1 illustrates a prior art method on a typical software package management system for installing a software package. The prior art software package management system, at step 102, performs a dependency check. If the required software packages are determined, at step 104, to be available then the management system performs, at step 108 a conflicts check for the software package to be installed. If a required software package is not available, or a conflict is determined, at step 110, an error message, at steps 106 and 112 respectively, is generated. Only if all required software packages are available and no conflicts exist does the management system, at step 114, carry out pre-install tasks. A pre-install script is used to run a script before the actual installation of the script. The software package management system, at step 116, manages configuration files of the software package and then, at step 118, unpacks the actual application files to their proper locations and set the correct owner and permissions. Post install tasks, at step 120, are carried out. For example, a post-install script is executed if any required tasks are needed to be completed such as starting up a daemon or registering the newly installed application. A software package database, at step 122, is updated with information regarding the installed software package.
Although software package management systems and software packages provide a useful system for distributing the software packages and also managing the software packages when installed on a system, both components have numerous drawbacks, problems, and shortcomings.
One problem with current software package management systems is that although these systems work well for describing complex dependencies of an software package and its conflicts with other software packages, the current use is restricted to static application information. The current software package management systems do not allow for the description of dynamic run-time information. Also, only the system and user processes that were running at a particular time are logged. Versions of dependencies such as libraries that were used, run-time command options, and more are not determined. An accurate replication of the system on which the job was executed is not created.
Yet another problem is that currently there is no general way for a software package manager to tell if it is safe to uninstall a program. The best that existing solutions can do is tell if a file, such as a DLL in Windows, is in active use, or use specific lock files to signify that an application is in use. This method is not very complete, meaning that current systems often get halfway through an uninstall before they hit a file that is in use, or do not know to even check the lock file.
Yet another problem is that traditional software package managers allow for installation, uninstallation, and tracking of the install-state of only applications and not user processes (jobs). Once applications are installed, there is no consistent method for executing user processes that take advantage of the installed applications. Furthermore, while today's computation jobs are becoming increasingly complex and interdependent, software package management systems only manage software packages and do not handle the dependencies between jobs and installable applications. Jobs often have complex dependencies and existing systems require the specification of specific files that must exist and the creation of an environment under which a job will run. Also, in many instances the results or output of a job are available, but the runtime state or application state of the system were when the job was executed is not known.
A further problem is that the software packages contain applications that are designed to run on a specific set of hardware and software, and must specify that in the software package's meta-information, often called the software package descriptor. Most packaging systems use a single string such as “x86”, “mips” or “amd64” to represent the capabilities. Even a comprehensive scheme such as using the format “cpu-vendor-[kernel-]system” (i.e. “i686-pc-linux-gnu” or “i686-pc-cygwin”) is still not sufficient. For example, there are other important settings that software packages could depend on, and it is difficult to extend the software package when new capabilities arise. Using a single string forces each system to adopt a predefined platform.
Currently, the only way a software package can test for capabilities not present in the platform string is to begin the install process and do the testing using platform-specific testing during the preinstall phase that are likely not portable and would need to be designed individually for each system. If the capabilities are not supported, the install process aborts. If the problem install is part of a series of installs, it may leave a system with many unnecessary software packages that were installed as prerequisites to the aborted software package.
Yet another problem is that systems that try to use packages to define an entire platform only use a single package that contains a file which holds the capabilities information. This capability information does not extend to the packaging system whereby other packages would depend on specific capabilities present on the system. This type of single package has the same problem as a string descriptor in that it is not easily extendable if a capability, either hardware or software, is added to a system. If the capabilities of multiple systems were to be combined such as the files system standard from Redhat, a Su5E kernel and the Debian packaging system, a single package that is non-reusable would need to be created with the prior art methods.
Therefore a need exists to overcome the problems with the prior art as discussed above.